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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on 02/17/04 has been entered. 

2. The following is a non- final office action in response to the request for continued 
examination received on 02/17/04. Claims 1, 9, 28, 32, and 53 have been amended. Claims 54- 
69 have been added. Claims 1-16, 28-49, and 53-69 are now pending in this Application. 

Election/Restriction 

3. Newly submitted claims 60, 61, 66, and 67 are directed to an invention that is 
independent or distinct from the invention originally claimed for the following reasons: claims 
60, 61, 66, and 67 are attempting to create a combination of Group I and II from the restriction 
requirement of paper number 7. Claims 60, 61, 66, and 67 are directed to the subject matter of 
restricted claims 17-27, which dealt with prioritizing requesters and establishing requestors' 
relationships to the target for priority reasons. As with claims 17-27, claims 60, 61, 66, and 67 
are related to a subcombination useable together with claims 1-16, 28-49, 53-59, 62-65, and 68- 
69. 

Claim Rejections - 35 USC § 112 

4. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 
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Claim 64 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

Claims 64 recites "a display showing an ID of a requesting user who has requested a 
meeting with the owning user and an availability status of the requesting user, the availability 
status sent by the requesting user" and "a display showing an ID of a target user with whom the 
owning user has requested a meeting, the availability status of a requesting user sent by the 
requesting user". It is unclear as to what is occurring in this claim or how the limitations 
interrelate. The first limitation suggests that a requesting user has requested a meeting with an 
owning user. The second limitation suggests that the owning user has requested a meeting a 
target user, and that the availability of a requesting user is sent. Therefore, there is no coherent 
link between these two limitations. Clarification is required. 

Claim Rejections - 35 USC § 102 
5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent. 

(e) the invention was described in a patent granted on an application for patent by another filed in the United 
States before the invention thereof by the applicant for patent, or on an international application by another who 
has fulfilled the requirements of paragraphs (1), (2), and (4) of section 371(c) of this title before the invention 
thereof by the applicant for patent. 

The changes made to 35 U.S.C. 102(e) by the American Inventors Protection Act of 1999 
(AIPA) do not apply to the examination of this application as the application being examined 
was not (1) filed on or after November 29, 2000, or (2) voluntarily published under 35 U.S.C. 
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122(b). Therefore, this application is examined under 35 U.S.C. 102(e) prior to the amendment 
by the AIPA (pre-AIPA 35 U.S.C. 102(e)). 

Claims 17-27, 49, and 53-57 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Vardi et al. (U.S. 6,389,127). 

6. As per claim 1, Vardi et al. discloses a computer-implemented method for the 
intermediation of real time meetings, comprising: 

Receiving an indication by a requester system that a requester wants to request a real time 
meeting with a target (See column 1, lines 53-56 and column 5, lines 22-31, which disclose a 
user at a request server wanting to request a real time meeting with a target); 

Sending to the target a request to conduct a real time meeting (See column 5, line 67, 
column 6, lines 1-5, 6-13, and 26-32, and column 7, lines 50-59, which discloses the request 
server sending to the target a request); 

After sending the request, sending by the requester system an availability status of the 
requester (See at least column 2, lines 65-67, column 3, lines 1-9, 15-28, and 40-45, column 7, 
lines 25-30 and 49-67, and column 8, lines 1-6, wherein after the requester send the request, the 
status of the requester is also sent by the requester system to the system); 

Queuing the request by the requester system (See column 5, lines 41-43 and 62-63, 
column 6, lines 6-12, and column 7, 39-44 and 57-64, wherein the request of the requestor is 
held and considered pending until the requested parties are available for the requested meeting to 
occur. The request of the requester does not reach the target until he is available to view the 
request); and 
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Connecting the requester and the target when the requester and the target are mutually 
available (See column 7, lines 39-48 and 53-67, which discuss the connecting of calls). 

Vardi et al. discloses a system that allows a requester using a requestor system to send a 
request for a conference to the system of a target and determine the availability of the target. A 
"middle man" has availability information concerning both the requester and the target. If the 
target is not currently available, the request of the requester waits for the target to become 
available and then the request is dealt with. When both the requester and the target are available, 
the parties are connected and the conference occurs. 

7. As per claim 2, Vardi et al. discloses a method that further comprises dequeuing the 
request when the real time meeting successfully completes (See column 6, lines 9-12 and column 

7. lines 39-43, wherein when the request for conference completes, the parties' status once again 
reflects availability and the previously pending request is then nonexistent). 

8. As per claim 3, Vardi et al. discloses a method wherein a system of the target is polled to 
determine the target's availability (See column 5, lines 22-25 and 67 and column 6, lines 1, 9-12, 
and 26-32, wherein the target is polled via a status acquirer to determine the availability of the 
target). 

9. As per claim 4, Vardi et al. discloses a method wherein the system of the target sends the 
target's availability status to the requester (See column 6, lines 9-12, 26-32, and 54-59, and 
column 7, lines 39-43 and 49-67, wherein the target's availability is sent to the requester via the 
request server and the status acquirer). 

1 0. As per claim 5, Vardi et al. discloses a method wherein a system of the requester is polled 
to determine the requester's availability (See column 5, 66-67, column 6, lines 1, 6-10, and 54- 
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59, column 7, lines 49-67, and column 8, lines 1-6 wherein the target initiates a request for the 
status of the requester and the process repeats itself in the opposite manner. See specifically 
column 8, lines 3-6). 

11. As per claim 6, Vardi et al. discloses a method wherein a system of the requester sends 
the requester's availability status to the target (See column 5, 66-67, column 6, lines 1, 6-10, and 
54-59, column 7, lines 39-43 and 49-67, and column 8, lines 1-6, wherein the target initiates a 
request for the status of the requester and the process repeats itself in the opposite manner, the 
status of the requester being delivered to the target. See specifically column 8, lines 3-6). 

12. As per claim 7, Vardi et al. discloses a method wherein mutual availability is determined 
by checking the availability of the requester and the target (See column 7, lines 39-43, 49-64, 
and 65-67, and column 8, 1-6, which discloses the callback function, wherein the requester 
requests a conference with the target and upon his/her availability, the target subsequently 
requests from the requester a real time meeting. See specifically column 8, lines 3-6. The 
process repeats until both parties are available for the real time meeting at which point the 
meeting initiates). 

13. As per claim 8, Vardi et al. discloses a method wherein the request is sent to a plurality of 
targets and mutual availability is determined when the requester and a quorum of the targets are 
available (See column 7, lines 49-64, wherein the conference call is initiated when the requester 
and the people currently available on the request for a conference call are ready). 

14. As per claim 9, Vardi et al. discloses a computer-implemented method for the 
intermediation of real time meetings, comprising: 
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Receiving, by a target system from a requester system, an indication that a requester 
wants to request a real time meeting with a target (See column 1, lines 53-56, column 5, lines 22- 
31, lines 1-9, column 7, lines 39-48, and column 8, lines 1-6, which disclose the requester system 
indicating through a request sent to the target system that a user of the requester system desires a 
real time meeting. See also column 5, line 67, and column 6, lines 1-9, which explains the 
request server associated with the request system sending a request to the status acquirer 
associated with the target system); 

Queuing the request by the target system (See column 5, lines 41-43 and 62-63, column 
6, lines 6-12, and column 7, 39-44 and 57-64, wherein the request of the requestor is held and 
considered pending until the requested parties are available for the requested meeting to occur. 
The request of the requester does not reach the target until he is available to view the request); 

Receiving, by the target, an availability status of the requester (See at least column 2, 
lines 65-67, column 3, lines 1-9, 15-28, and 40-45, column 7, lines 25-30 and 49-67, and column 
8, lines 1-6, wherein the status of the requester is sent by the requester system to the target); and 

Connecting the requester and the target when the requester and the target are mutually 
available (See column 7, lines 39-48, 51-55, and 59-65, and column 8, lines 1-6, wherein 
initiation of a real time meeting/conference between available parties is disclosed). 
15. As per claim 10, Vardi et al. discloses a method further comprising dequeuing the request 
when the real time meeting successfully completes (See column 6, lines 9-12 and column 7, lines 
39-43, wherein when the request for conference completes, the parties' status once again reflects 
availability and the previously pending request is then nonexistent). 
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16. As per claim 11, Vardi et al. further discloses a method wherein a system of the target is 
polled to determine the target's availability (See column 5, lines 22-25 and 67 and column 6, 
lines 1, 9-12, and 26-32, wherein the target is polled via a status acquirer to determine the 
availability of the target). 

17. As per claim 12, Vardi et al. further discloses a method wherein the system f the target 
sends the target's availability status to the requester (See column 6, lines 9-12, 26-32, and 54-59, 
and column 7, lines 39-43 and 49-67, wherein the target's availability is sent to the requester via 
the request server and the status acquirer). 

18. As per claim 13, Vardi et al. further discloses a method wherein the system of the 
requester is polled to determine the requester's availability (See column 5, 66-67, column 6, lines 
1,6-10, and 54-59, column 7, lines 49-67, and column 8, lines 1-6 wherein the target initiates a 
request for the status of the requester and the process repeats itself in the opposite manner. See 
specifically column 8, lines 3-6). 

19. As per claim 14, Vardi et al. further discloses a method wherein the system of the 
requester send the requester's availability status to the target (See column 5, 66-67, column 6, 
lines 1, 6-10, and 54-59, column 7, lines 39-43 and 49-67, and column 8, lines 1-6, wherein the 
target initiates a request for the status of the requester and the process repeats itself in the 
opposite manner, the status of the requester being delivered to the target. See specifically 
column 8, lines 3-6). 

20. As per claim 15, Vardi et al. discloses a method wherein mutual availability is 
determined by checking the availability of the requester and the target (See column 7, lines 39- 
43, 49-64, and 65-67, and column 8, 1-6, which discloses the callback function, wherein the 
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requester requests a conference with the target and upon his/her availability, the target 
subsequently requests from the requester a real time meeting. See specifically column 8, lines 3- 
6. The process repeats until both parties are available for the real time meeting at which point 
the meeting initiates). 

21. As per claim 16, Vardi et al. further teaches a method wherein a request is sent to a 
plurality of targets and mutual availability is determined when the requester and a quorum of the 
targets are available (See column 7, lines 49-64, wherein the conference call is initiated when the 
requester and the people currently available on the request for a conference call are ready). 

22. As per claim 28, Vardi et al. teaches a computer-implemented method for the 
intermediation of real time meetings, comprising: 

receiving an indication that a requestor party wants to request a real time meeting with 
one or more target parties (See column 5, lines 22-38 and 62-63, and column 6, lines 6-8, which 
discloses the systems of the target parties receiving indications that the requestor party wants to 
arrange a real time meeting); 

receiving information indicating the availability of the requester party and one or more 
target parties to participate in the real time meeting, the information sent by the respective party 
and indicating a desire of a human being to take part in a meeting (See column 5, lines 62-63, 
column 6, lines 6-9, and column 7, lines 39-48, 49-52, and 57-65, wherein information is 
requested and received concerning the availability of a requester and the availability of target 
parties. See column 6, lines 9-12 and 26-32, and column 7, lines 26-31, which discuss different 
types of availability); 
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determining that the requester party and one or more target parties are mutually available 
to participate in the real time meeting, in response to the received information (See column 7, 
lines 39-48, 49-52, and 57-65, wherein it is determined whether the parties are mutually 
available. See column 6, lines 9-12 and 26-32, and column 7, lines 26-31, which disclose ways 
of measuring availability); and 

responsive to the determination that the requester party and one or more target parties are 
mutually available to participate in the real time meeting, initiating the real time meeting (See 
column 7, lines 39-48, 49-52, and 57-65, wherein the real time meeting is initiated when all 
parties are available). 

23. As per claim 29, Vardi et al. discloses a computer-implemented method wherein the 
initiating further comprises informing the requester party and one or more target parties that they 
should initiate communication (See column 7, lines 39-47 and 65-67, and column 8, lines 1-6, 
wherein a request for conference/real time meeting is accompanied with a request to initiate 
communication with the requester. The requester has the ability to either initiate the meeting 
when the requester receives status information about the target or the request can be delivered 
with information about the status of the requester (available, not available for meeting) and 
request the target to initiate the contact). 

24. As per claim 30, Vardi et al. teaches a computer-implemented method wherein the 
initiating further comprises requesting the requestor party and one or more target parties to open 
a connection (See column 7, lines 39-47 and 49-67, and column 8, lines 1-6, wherein the request 
informs parties to open connections in order to participate in the conference/real time meeting). 
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25. As per claim 31, Vardi et al. teaches a computer-implemented method wherein the 
availability of the requestor party and one or more target parties is determined by checking at 
least one of: start or end of a call, other use of a phone, recent activity at the computer input 
devices, conversation near a microphone, lights turned on/off, weight in chair or on floor, motion 
sensor, opening/closing of door, spoken commands, computer keyboard/mouse based 
commands, touchtone commands, and scheduled periods of availability (See column 6, lines 9- 
12, 26-32, and column 7, lines 26-31, wherein different ways to determine a party's availability 
are disclosed). 

26. As per claim 32, Vardi et al. discloses a system for intermediation of real time meetings, 
comprising: 

a requester system for receiving a request from a requester party to initiate a real time 
meeting with one or more target parties associated with target systems (See column 1, lines 53- 
56, and column 5, lines 22-31, which disclose a user sending a request to a request server to 
initiate a real time meeting. See also column 7, lines 49-59, which discloses one or more target 
parties); 

a first server system associated with the requester system, the first server system for 
determining availability of the requester party and sending the availability of the requester party 
(See column 5, lines 62-63, column 6, lines 6-9, and column 7, lines 39-48, wherein a status 
acquirer resides on the system of the requester and determines the availability of the requester. 
See at least column 2, lines 65-67, column 3, lines 1-9, 15-28, and 40-45, column 7, lines 25-30 
and 49-67, and column 8, lines 1-6, wherein the status of the requester is also sent); 
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a second server system associated with a target system, the second server system for 
determining availability of one or more target parties and sending the availability of at least one 
of the target parties (See column 5, lines 62-63, column 6, lines 6-9, and column 7, lines 39-48, 
wherein a status acquirer resides on the system of the target and determines the availability of the 
target. See at least column 2, lines 65-67, column 3, lines 1-9, 15-28, and 40-45, column 7, lines 
25-30 and 49-67, and column 8, lines 1-6, wherein the availability of at least one of the target 
parties is sent); and 

a deciding agent in communication with the first server system, the second server system, 
the requester system, and the target system, the deciding agent for recording the request for the 
real time meeting, for receiving an indication that each the requester party and one or more target 
parties are available for the real time meeting, for determining whether the requester party and 
one or more target parties are mutually available for the real time meeting, and for initiating the 
real time meeting when all parties are mutually available (See column 1, lines 53-58, column 5, 
lines 62-66, column 7, lines 49-52 and 57-67, and column 8, lines 1-6, wherein a "middleman" 
decides when the two parties are mutually available, based on their received status information, 
and initiates a real time meeting/conference between the parties). 

27. As per claim 33, Vardi et al. discloses a system wherein each the first server system and 
the second server system is further adapted to record the request for the real time meeting (See 
column 7, lines 39-47, wherein the request information is stored on the system of the 
requester/target user before action takes place). 

28. As per claim 35, Vardi et al. teaches a system wherein the deciding agent is further 
adapted to communicate to the first server system to cease sending an indication that the 



Application/Control Number: 09/416,278 Page 13 

Art Unit: 3623 

requester party is available for the real time meeting (See column 6, lines 9-17, in which the 
physical status of the user is communicated to the status acquirer, and the status therefore reflects 
when the user ceases to be available. See also column 6, lines 26-32, and column 7, lines 26-3 1, 
which disclose other reason the user may be unavailable. Finally, see column 7, lines 49-65, 
wherein a mediator decides to conference the calls when all parties are available to meet. This 
agent would affect the status ascertained during a status check by another requester, and the 
requestor would consequently be unavailable). 

29. As per claim 36, Vardi et al. discloses a system wherein the deciding agent is further 
adapted to communicate to the second server system to cease sending an indication that the 
target party is available for a real time meeting (See column 6, lines 9-17, in which the physical 
status of the user is communicated to the status acquirer, and the status therefore reflects when 
the user ceases to be available. See also column 6, lines 26-32, and column 7, lines 26-31, which 
disclose other reason the user may be unavailable. Finally, see column 7, lines 49-65, wherein a 
mediator decides to conference the calls when all parties are available to meet. This agent would 
affect the status ascertained during a status check by another requester, and the target would 
consequently be unavailable). 

30. As per claim 37, Vardi et al. teaches a system wherein the deciding agent is further 
adapted to poll the first server system to determine the availability of the requester party (See 
column 7, lines 49-65, wherein the status acquirer of the first server system is polled to 
determine the user's availability). 

31. As per claim 38, Vardi et al. teaches wherein the deciding agent is further adapted to poll 
the second server system to determine the availability of the target party (See column 7, lines 49- 
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65, wherein the status acquirer of the first server system is polled to determine the user's 
availability). 

32. As per claim 39, Vardi et al. discloses a system wherein the deciding agent is located at 
the target system (See column 7, lines 39-48, wherein the deciding agent that arranges the 
meeting and determines the availability of the parties for said meeting is located in the system of 
the target). 

33. As per claim 40, Vardi et al. teaches a system wherein the requester system is further 
adapted to record the request to conduct the real time meeting (See column 7, lines 39-47, 
wherein the request information is stored on the system of the requester user before any action or 
initiation takes place). 

34. As per claim 41, Vardi et al. teaches a system wherein the target system is further adapted 
to reject a request to add one or more target parties to the real time meeting and to communicate 
the rejection to the deciding agent (See column 6, lines 33-38 and 47-59, wherein the inability 
for a requester to poll a target is disclosed). 

35. As per claim 42, Vardi et al. discloses a system wherein the target system is further 
adapted to receive an indication that the requester party and one or more target parties are 
available by monitoring the activity of the requester party and one or more target parties (See 
column 6, lines 9-12 and 26-32, and column 7, lines 26-31, wherein different ways to determine 
the availability of the requestor and/or target parties is disclosed). 

36. As per claim 43, Vardi et al. discloses a system wherein the real time meeting is 
conducted using the telephone (See column 1, lines 53-58). 
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37. As per claim 44, Vardi et al. teaches a system wherein the real time meeting is conducted 
using Internet telephony (See column 7, lines 31-34). 

38. As per claim 49, Vardi et al. teaches a system further comprising a plurality of requester 
parties and a plurality of target parties, and wherein the deciding agent initiates the real time 
meeting when a quorum of the requestor parties and target parties is available (See column 7, 
lines 49-64, wherein the conference call is initiated when the requesters and the targets currently 
available for the requested real time meeting/conference call are ready. Finally see column 1, 
lines 55-56, which discloses multiple requesting parties). 

39. As per claim 53, Vardi et al. discloses a computer program product stored on a computer 
readable medium for intermediation of real time meetings, the computer program product 
comprising: 

program code for receiving an indication that a requester party wants to request a real 
time meeting with one or more target parties (See column 5, lines 22-38 and 62-63, and column 
6, lines 6-8, which discloses the systems of the target parties receiving indications that the 
requestor party wants to arrange a real time meeting); 

program code for receiving information indicating the availability of the requester party 
and one or more target parties to participate in the real time meeting, the information sent by the 
respective party and indicating a desire of a human being to take part in a meeting (See column 
5, lines 62-63, column 6, lines 6-9, and column 7, lines 39-48, 49-52, and 57-65, wherein 
information is requested and received concerning the availability of a requester and the 
availability of target parties. See column 6, lines 9-12 and 26-32, and column 7, lines 26-31, 
which discuss different types of availability); 



Application/Control Number: 09/416,278 Page 16 

Art Unit: 3623 

program code for determining that the requester party and one or more target parties are 
mutually available to participate in the real time meeting, in response to the received information 
(See column 7, lines 39-48, 49-52, and 57-65, wherein it is determined whether the parties are 
mutually available. See column 6, lines 9-12 and 26-32, and column 7, lines 26-31, which 
disclose ways of measuring availability); and 

program code for initiating the real time meeting, responsive to the determination that the 
requester party and one or more target parties are mutually available to participate in the real 
time meeting (See column 7, lines 39-48, 49-52, and 57-65, wherein the real time meeting is 
initiated when all parties are available). 

40. As per claim 54, Vardi et al. teaches a method further comprising displaying the 
availability status of the requester on the target system, along with an indication that the 
requester has requested a meeting (See at least column 1, lines 50-67, column 6, lines 5-32, 
column 7, lines 20-30 and 39-67, wherein the availability status of the requestor is shown to the 
target system in the server along with an indication that a meeting was requested). 

41. As per claim 55, Vardi et al. teaches a method wherein the availability status is one of in, 
out, and unknown (See at least column 6, lines 5-20 and 25-35, which discusses the availability 
status of the user). 

42. As per claim 56, Vardi et al. teaches a method further comprising displaying an 
availability status of the target on the requester system, along with an indication that the 
requestor has requested a meeting with the target (See at least column 1, lines 50-67, column 6, 
lines 5-32, column 7, lines 25-30 and 49-67, and column 8, lines 1-6, wherein the availability 
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status of the target is displayed on the requester system with an indication that the requestor has 
requested a meeting). 

43. As per claim 57, claim 57 recites similar and equivalent limitations to claim 55, and is 
therefore rejected using the same art and rationale relied on in the rejection of claim 55. 

44. Claims 58-59, 62-65, and 68-69 are rejected under 35 U.S.C. 102(a) as being anticipated 
by ICQ (www.icq.com). 

45. As per claim 58, ICQ teaches a user interface displayed on a target system, comprising: 

a display showing an ID of a requesting user who has requested a meeting with the target 
(See at least pages 5, 9-10, 16-17, 29, 30, and 34-36, which disclose a display showing the ID of 
the requesting user); and 

a display showing the availability status of a requesting user, the availability status sent 
by the requesting user (See at least pages 5, 9-10, 16-17, 29, 30, and 34-36, which discloses 
showing the availability status in the display). 

46. As per claim 59, ICQ teaches wherein the availability status is one of in, out, and 
unknown (See at least pages 5, 9-10, 16-17, 29, 30, and 34-36, wherein the availability status is 
in, out, or unavailable, etc.). 

47. As per claim 62, ICQ teaches showing a reason for the requested meeting (See at least 
pages 5, 9-10, 16-17, 29, 30, and 34-36, wherein the reason is shown, such as the need to discuss 
tomorrow's presentation). 
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48. As per claim 63, ICQ teaches showing additional information about the requesting user 
(See at least pages 5, 9-10, 16-17, 29, 30, and 34-36, wherein the nickname for the user and the 
ID are at the leas shown. Other personal information can be entered in the system). 

49. As per claim 64, ICQ teaches a user interface displayed on a system of an owning user, 
comprising: 

a display showing an ID of a requesting user who has requested a meeting with the 
owning user and an availability status of the requesting user, the availability status sent by the 
requesting user (See at least pages 5, 9-10, 16-17, 29, 30, and 34-36, which discloses showing 
the ID and the availability status of a requester in a display); and 

a display showing an ID of a target user with whom the owning user has requested a 
meeting, the availability status of a requesting user sent by the requesting user (See at least pages 
5, 9-10, 16-17, 29, 30, and 34-36). 

50. As per claim 65, claim 65 recites similar and equivalent limitations to claim 59, and is 
therefore rejected using the same art and rationale relied on in the rejection of claim 59. 

51. As per claim 68, claim 68 recites similar and equivalent limitations to claim 62, and 
therefore is rejected using the same art and rationale relied on in the rejection of claim 62. 

52. As per claim 69, claim 69 recites similar and equivalent limitations to claim 63, and is 
therefore rejected using the same art and rationale relied on in the rejection of claim 63. 

Claim Rejections - 35 USC § 103 

53. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 
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(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

54. Claim 34 is rejected under 35 U.S.C. 103(a) as being unpatentable over Vardi et al. (U.S. 
6,389,127). 

55. As per claim 34, Vardi et al. discloses a system wherein each the first server system and 
the second server system is adapted to receive and record a request for the real time meeting (See 
column 7, lines 39-48, wherein the request is received and recorded in the software of the target 
computer). However, Vardi et al. does not expressly disclose the first and second server system 
being adapted to delete the request for the real time meeting. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to adapt the first and second server systems to be able to delete the request for the real time 
meeting because deleting the original request for real time meeting upon the meeting's 
rescheduling or upon the conclusion of the event of the meeting is old and well known. One 
would be motivated to delete a request upon its acceptance because its removal would allow the 
system to maintain precise and easily readable records about the availability of a target and also 
minimize the use of memory in the process. By deleting requests directed at a specific target, a 
requester system polling the availability of said target would be able to easily ascertain its status 
without having to follow a trail of records. 

56. Claims 45-48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Vardi et al. 
(U.S. 6,389,127) in view of Microsoft NetMeeting ("Microsoft NetMeeting 2.0: Overview and 
Frequently Asked Questions"). 
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57. As per claims 45-48, Vardi et al. discloses a system wherein the real time meeting is 
specified as a telephone conferencing, an Internet telephone, or communication devices using 
CATV as part of the network infrastructure (See column 7, lines 31-38, wherein different types 
of real time meetings are disclosed). However, Vardi et al. does not expressly disclose a system 
wherein the real time meeting is specified as a text chat, an online collaboration tool, or a shared 
application. 

Microsoft NetMeeting discloses a wherein the real time meeting is specified as a text 
chat, an online collaboration tool, or a shared application: 

i. As per claim 45, Microsoft NetMeeting discloses a system wherein the real time 
meeting is specified as a face-to-face meeting (See pages 1 and 4, wherein Microsoft 
NetMeeting discusses NetMeeting's ability to hold face-to-face real time 
meetings/conferences) . 

ii. As per claim 46, Microsoft NetMeeting discloses a system wherein the real time 
meeting is specified as a text chat (See page 5, wherein Microsoft NetMeeting discusses 
NetMeeting's ability to conduct real time chat sessions). 

iii. As per claim 47, Microsoft NetMeeting teaches a system wherein the real time 
meeting is an online collaboration tool (See page 5, wherein Microsoft NetMeeting 
discusses NetMeeting's capability of white boarding and shared clipboards, which allow 
the parties in the real time meeting to collaborate). 

iv. As per claim 48, Microsoft NetMeeting discloses a system wherein the real time 
meeting is a shared application (See page 4, which discloses NetMeeting's application 
sharing capabilities). 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include a text chat, online collaboration tool, and/or shared applications as additional tools for 
conducting real time meetings because the incorporation of these old and well known capabilities 
would have increased the usefulness of the product to potential buyers, thus making the 
notification system more marketable. 

Response to Arguments 
58. Applicant's arguments with regard to the § § 102 and 103 rejections based on Vardi et al. 
(U.S. 6,389,127) and Microsoft NetMeeting ("Microsoft NetMeeting 2.0: Overview and 
Frequently Asked Questions") have been fully considered but they are not persuasive. In the 
remarks, the Applicant argues that Vardi et al. does not teach or suggest (1) the requester sending 
a request to the target as well as the requester sending a status of the requester to the target and 
(2) that line status is sent by the seeking user to the sought user. Applicant further argues (3) 
with respect to claim 34 the Examiner's contention that it would have been obvious to one of 
ordinary skill in the art to modify Vardi et al. to remove meetings from a queue and asks the 
Examiner to provide support and (4) that Examiner used impermissible hindsight when 
combining Vardi et al. and Microsoft NetMeeting. 

In response to argument (1), the Examiner respectfully disagrees. Vardi et al. discloses a 
requesting user operating a requester system (i.e. computer/communications terminal on a 
communications network) and a target user operating a target system (i.e. 
computer/communications terminal on a communications network). The requester via the 
requester system and the target via the target system send status information to the servers. 
Therefore, does teach sending a status of the requester to the target as it is claimed in the 
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limitations. For example, claim 1 recites "Sending to the target a request to conduct a real time 
meeting" and "After sending the request, sending by the requester system an availability status of 
the requester ". Vardi et al. dislcoses these limitations in at least column 2, lines 65-67, column 
3, lines 1-9, 15-28, and 40-45, column 5, line 67, column 6, lines 1-5, 6-13, and 26-32, column 7, 
lines 25-30 and 50-59. Examiner points out that the claims require that at some point after the 
request is sent that the availability status is sent by the system of the requester (i.e. no recitation 
of how, in what form, at what specific time, etc.). Vardi et al. discusses that the target system 
would try to begin the meeting after receiving an indication that the requester is available (for 
example, the phone line is not busy). Claims 5, 13, and 37, for example, further recite how it is 
the system of the requester that is polled to determine the availability of the requester, as 
disclosed by Vardi et al. Therefore, Examiner maintains that Vardi et al. does disclose the 
claimed limitations which require the requester system requesting a real time meeting and then, 
at some later point, the requester system sending the requester's availability status. 

In response to argument (2), the Examiner respectfully disagrees. Vardi et al. does teach 
that line status is sent by the seeking user to the sought user, as discussed in response to 
argument (1). 

In response to argument (3), the Examiner would first like to point out that she stated that 
it would have been obvious to one of ordinary skill in the art at the time of the invention to adapt 
the first and second server systems to be able to delete the request for the real time meeting, and 
not that it would have been obvious to modify Vardi et al. to remove meetings from a queue. In 
fact, nothing in claim 34 or in claim 32 (the claim from which claim 34 depends) discusses 
removing meetings from a queue. If this feature is important to the invention, the Examiner 
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suggests clearly reciting it in the body of claim 32 or 34. Second, Examiner maintains that it 
would have been obvious to one of ordinary skill in the art at the time of the invention to adapt 
the first and second server systems to be able to delete the request for the real time meeting 
because it is old and well known to delete the original request for real time meeting upon the 
meeting's rescheduling or upon the conclusion of the meeting. Smythe et al. (U.S. 6,418,214) is 
just one example of a person in the art that deletes a meeting request once the meeting is 
established. Smythe et al. discloses that upon a meeting being established, the server inspects 
status of the request in the conference-request table and deletes the request. See at least column 
5, lines 20-45, and column 9, lines 35-55. One would be motivated to delete a request upon its 
acceptance because its removal would allow the system to maintain precise and easily readable 
records about the availability of a target and also minimize the use of memory in the process. 
Smythe et al. also discuss this in column 2, lines 30-45, column 3, lines 35-45, and column 7, 
lines 1-30. 
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In response to argument (4), the Examiner respectfully disagrees. It must be recognized 
that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight 
reasoning. But so long as it takes into account only knowledge which was within the level of 
ordinary skill at the time the claimed invention was made, and does not include knowledge 
gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re 
McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Since both Vardi et al. and 
Microsoft NetMeeting discuss network based conferencing, it would have been obvious to 
combine the features. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

Weber ("Net Interest") teaches discusses business items, such as projects, on-line. 
ICQ Press Center ("ICQ for Windows 95") discloses conducting business meetings and 
conferencing over a network. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Beth Van Doren whose telephone number is (703) 305-3882. 
The examiner can normally be reached on M-F, 8:30-5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tariq Hafiz can be reached on (703) 305-9643. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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